home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 3 / BBS in a box - Trilogy III.iso / Files / Prog / U-Z / VideoToolBox Folder / Notes / GWorld baseAddress < prev    next >
Encoding:
Text File  |  1992-02-11  |  6.4 KB  |  129 lines  |  [TEXT/ttxt]
  1. Macintosh GWorld baseAddresses
  2.  
  3. How can I transform the content of a GWorld on a NuBus™ card? The idea is to
  4. clone the GWorld, copy the data to the card, transform them, patch the address
  5. into the GWorld, and display them directly on the screen. I´d like to do it in
  6. a way that works well with the 8•24 GC and similar asynchronous QuickDraw
  7. stuff.
  8. ___
  9.  
  10. NewGWorld allocates off-screen buffers simply by using the same Memory Manager
  11. calls that you and I make. To actually allocate the memory it simply calls
  12. NewHandle to allocate the buffer in your application’s heap if you have the
  13. useTempMem (née useMFTemp) bit clear. It then tries to move it as high in your
  14. heap as possible by calling MoveHHi. If you have the useTempMem bit set, then
  15. NewGWorld uses the temporary memory calls to allocate the off-screen buffer in
  16. temporary memory, and then it tries to move it as high as possible in the
  17. temporary memory space. That’s really all there is to it. The GWorld’s PixMap,
  18. GDevice and CGrafPort are allocated similarly—they’re all allocated in your
  19. heap using regular Memory Manager calls with no special options, patches, or
  20. other nefarious tricks.
  21.  
  22. None of this changes when you have the 8•24 GC software active—all memory is
  23. allocated out of your application’s heap. Once you start drawing into the
  24. GWorld, though, the GC software can copy the parts of a GWorld to the 8•24 GC
  25. memory. The GWorld and its parts go still occupy your heap’s memory though,
  26. regardless of whether it’s cached on the 8•24 GC card or not.
  27.  
  28. If you have a NuBus card with gobs of memory, NewGWorld can’t take advantage
  29. of it because the Memory Manager calls that it uses can’t allocate memory on
  30. NuBus memory cards. There are no options to NewGWorld or any other GWorld
  31. calls that let you say, “there’s lots of memory over on this NuBus card, all
  32. for you.” That means that GWorlds aren’t appropriate if you want to have
  33. control over where the off-screen buffer is allocated. Conceivably, you could
  34. allocate a GWorld, stuff the address of your NuBus memory card into the
  35. baseAddr of your GWorld’s PixMap, and then put the constant baseAddr32 into
  36. its pmVersion field, but engineering here didn’t feel very comfortable with
  37. that idea because of compatibility concerns.
  38.  
  39. QuickDraw is the only thing that’s supposed to know how GWorlds are
  40. constructed. We know that they’re CGrafPorts and we can get their PixMap,
  41. GDevice, and off-screen buffer, but we can’t make any assumptions about how
  42. they were allocated and where they are. For example, we know that the off-
  43. screen buffer is allocated as a handle now, but that won’t necessarily be the
  44. case in the future. There’s no guaranteed way to tell which way it was
  45. allocated, or even if NewGWorld uses the Memory Manager to allocate it at all
  46. (which it always does currently of course). Even the GWorld’s CGrafPort is
  47. allocated as a handle which just happens to be always locked. If you try to
  48. dispose of a GWorld in which you’ve modified the baseAddr, you’ll need
  49. DisposeGWorld to make sure everything is deallocated properly, but it’ll act
  50. unpredictably when it tries to deallocate the off-screen buffer.
  51.  
  52. So if you want to use the memory on your NuBus memory card, you’re going to
  53. have to create your own PixMap, color table (if it needs one), GDevice, and
  54. CGrafPort. Technical Note #120, “Drawing Into an Off-Screen PixMap” covers
  55. creating your own PixMap, CGrafPort, and color table, but it has the same
  56. depth and equivalent color table to the screen, so it just steals a screen’s
  57. GDevice. I think it’s always a good idea to create your own GDevice when you
  58. draw off screen. If you use a screen’s GDevice, then you have to depend on
  59. that GDevice’s depth and color table. By creating your own GDevice, your off-
  60. screen drawing can use any depth and color table you want at any time, and
  61. Color QuickDraw won’t choke.
  62.  
  63. To create your own GDevice, it’s better not to use NewGDevice because it
  64. always creates the GDevice in the system heap, and it’s just better to keep
  65. your own data structures in your own heap. Here’s what you should set each of
  66. its fields to be:
  67.  
  68. gdRefNum     - Your GDevice has no driver, so just set this to zero.
  69.  
  70. gdID         - It doesn’t matter what you set this to; might as well set it
  71.                to zero.
  72.  
  73. gdType       - Set this to 2 if your off screen uses direct colors (16 or
  74.                32 bits per pixel) or 0 if your off screen uses color table
  75.                (1 through 8 bits per pixel).
  76.  
  77. gdITable     - Allocate a small (maybe just 2-byte) handle for this field.
  78.                After you’re done setting up this GDevice and your off-screen
  79.                PixMap, color table (if any) and CGrafPort, then set this
  80.                GDevice as the current GDevice by calling SetGDevice, and then
  81.                call MakeITable, passing it NIL for both the color table and
  82.                inverse table parameters, and 0 for the preferred inverse
  83.                table resolution.
  84.  
  85. gdResPref    - I’d reckon that more than 99.9% of all inverse tables out
  86.                there have a resolution of 4. Unless you have some reason not
  87.                to, I’d recommend the same here.
  88.  
  89. gdSearchProc - Set to NIL. Use AddSearch if you want to use a SearchProc.
  90.  
  91. gdCompProc   - Set to NIL. Use AddComp if you want to use a CompProc.
  92.  
  93. gdFlags      - Set to 0 initially, and then use SetDeviceAttribute after
  94.                you’ve set up the rest of this GDevice.
  95.  
  96. gdPMap       - Set this to be a handle to your off-screen PixMap.
  97.  
  98. gdRefCon     - Set this to whatever you want.
  99.  
  100. gdNextGD     - Set this to nil.
  101.  
  102. gdRect       - Set this to be equal to your off-screen PixMap’s bounds.
  103.  
  104. gdMode       - Set this to -1. Why? I’m not sure. This is intended for
  105.                GDevices with drivers anyway.
  106.  
  107. gdCCBytes    - Set to 0.
  108.  
  109. gdCCDepth    - Set to 0.
  110.  
  111. gdCCXData    - Set to 0.
  112.  
  113. gdCCXMask    - Set to 0.
  114.  
  115. gdReserved   - Set to 0.
  116.  
  117. For gdFlags, you should use SetDeviceAttribute to set the noDriver bit and the
  118. gdDevType bit. You should set the gDevType bit to 1 even if you have a
  119. monochrome color table. The 0 setting was only used for the days when
  120. monochrome mode was handled by the video driver, which 32-Bit QuickDraw
  121. eliminated. Your GDevice doesn’t have a driver anyway.
  122.  
  123. One last warning is that you should set the pmVersion field of your PixMap to
  124. be the constant baseAddr32 (equals 4). That tells Color QuickDraw to use 32-
  125. bit addressing mode to access your off-screen buffer, and that’s a requirement
  126. if your off-screen buffer is allocated on a NuBus card.
  127.  
  128. ©Apple Computer,  Inc.  1985-1991
  129.